Cream of the Crop 3/Cream of the Crop 3.iso/comm/prtcs155.zip/EMSI_LIN.DOC

Text File | 1994-01-14 | 17KB | 392 lines

$VER: EMSI_LINKS DOC  Shelter EMSI Implentation  Williamson 01.36
    Title:      Shelter EMSI Implementation
    Author:     Robert Williamson
    Version:    1.36 (March 19,1994)
    This article (c) Robert Williamson 1994

    Introduction:   EMSI - Who needs it?

    Although  Shelter Mailers have EMSI, I personally have no need of EMSI.
Shelter AUTOAKA WAZOO does everything I need and more.

    EMSI   capabilities   are   provided   by  the  only  freely  available
implementation   and   one  of  the  select  group  of  XPR  v3  libraries:
wplemsi.library  by  James McOrmond.  (XPRfts.library, XPRclock.library and
XPRzedzap.library are also XPR v3) It should be obvious by the inclusion of
the  clock  and emsi libraries that the XPR specification is not limited to
file transfer protocols.

    Much  discussion  has taken place as to why WPL mailers took so long to
support   EMSI.   The  concensus  has  been  that  since  neither  the  WPL
Application  developers nor the users of WPL-based mailers had found a need
for EMSI, the implementation of EMSI remained a very low priority.

    Although  many  users  of other mailers consider EMSI a requirement for
them  to forego their investment in commercial mailers, this perceived need
is  actually  a  false assumption.  There is virtually nothing in this area
that  cannot  be  done  with  Xferq compatible packer/routers and WPL-based
mailers.   As  has  been  demonstrated in a number of echos, every 'reason'
that has been presented for their perceived NEED for EMSI has been shown to
be  based NOT on the capabilities of EMSI, but rather, upon the LIMITATIONS
of  their  mailer  and  the  FLO  file  queueing  method.  Freely-available
WPL-based  mailers  do  not  have  those limitations.  Use of Xferq.library
routers and features such as AUTOAKA and USEAKAS under WAZOO remove many of
the  'reasons'.

    With this all said, here is HOW EMSI is implemented in Shelter Mailers.

    The  use  of  EMSI  presupposes  that  one's  Tosser is DOMAINAWARE (ie
Multi-FTN).    Options   have  been  added  to  permit  use  of  EMSI  with
non-DOMAINAWARE  tossers,  (tossers  that require multiple configs for each
network)  such  as  ConfMail  and TrapToss.  In my own case, using ConfMail
under AutoAKA WaZoo, multi-ftn is trivial, however, with EMSI, I must add a
step and sort packets by domain using FTNSORT.

    Definitions:
    Some terms are used which may not be familiar:

    Domain:
    In this document, refers to an FTN organization such as FidoNet
    or AmigaNet.

    Asname:
    The filename transmitted to a site.  It need not be the same as
    the local filename.
        eg:
            local:  mail:outbound/fidonet.1.167/141.0.MO1
            asname: 00000025.MO1

    AutoAKA:
    Shelter   feature   for  AKA  handling;  provides  domain  subsitution,
    presentation  of  proper  address  in domain of site called or calling,
    priority of known akas over presented akas and many other features used
    both in WaZoo and EMSI.  However, AUTOAKA's presentation of our primary
    address  in  the  domain  of the caller is not possible on INBOUND EMSI
    sessions at this time.

    Known AKAs:
    These  are  the  AKAs  we  have  listed in the Site Cache for the phone
    number of the primary address of a remote site.

    USEAKAS:
    A  feature  of  both  AUTOAKA  WAZOO  and SHELTER EMSI that asserts the
    primacy  of  the  KNOWN  akas  for a system over those presented.  This
    allows  one  to  send all files to a site for all that site's addresses
    for which we pack mail under either Wazoo or Emsi.

    BeginSession:
    This  is  a wpl command which asks Xferq.library for the list of files,
    asnames, priorities, dispositions and queue control flags for a site or
    list of sites.

    SetA:
    This  is  a wpl command which fixes an address and fills stem variables
    consisting of the components of the address.

    Handshake:
    Method  of  determining  who  is  calling.   There are four used:  FTS1
    (FTS0001) , WAZOO(FTS0006), EMSI(FSC0056) and UUCP.

    Site Cache:
    In-memory   list   of   sites,   passwords,   known  akas,  handshakes,
    aftersession  commands  and  other  variables  particular to a site, or
    phonenumber.

    Present(ed):
    The sending of EMSI data from one system to another.

    Examine(d):
    The parseing of received EMSI data.

    UMH:
    Universal  Mail  Hour,  also  known as ZMH (Zone Mail Hour).  This is a
    period  of  time  during  which  only netmail may be transferred.  When
    answering,  human,  uucp  and  fax  callers, file requests and archived
    echomail should be refused.   When calling, only netmail should be sent.
    It  is  assumed  that  compressed mail is echomail, which should not be
    transferred  during  this  period.   For  non-standard  systems running
    tossers  that  bundle or archive some netmail along with echomail, this
    is may not a viable option.



    Outbound EMSI Sessions:

    EMSI will not be attempted if disabled (as with WAZOO and FTS1) for the
particular LINE.

    EMSI  will not be attempted if a HANDSHAKE setting for the site exists,
and it does not contain EMSI (as with WAZOO and FTS1).

    If  EMSI  is  enabled  for  the  line  AND  for the site called, we use
wplemsi.library  to  monitor the line for an EMSI_REQ.  If none is received
or  the emsi handshake failed, we then monitor for other enabled handshakes
for the line and site called.  This second step includes EMSI.  Fallback to
DietIFNA is supported.


    Inbound EMSI Sessions:

    EMSI will not be attempted if disabled for the particular LINE.

    If the primary address is IN our Site Cache, we will check the password
presented  against  the  password  for the primary address.  If it does not
match,  we  HANGUP if the flag KILLBAD is TRUE.  This is viable as the EMSI
spec requires that the same password exist for all aka's presented.

    If KILLBAD is FALSE, we will force the site to NPU (no pickup) and do a
BeginSession  with  site  BADPASSWORD.  A textfile describing the situation
should  be  queued for this address with priority 75 and disposition Leave.
This  action  was  suggested  by  James  McOrmond.  This still allows us to
receive files from the site in our NONSECURE inbound.

    Once  a  carrier  is  established,  our  banner is sent, and if EMSI is
enabled  for  the LINE, an EMSI_REQ (followed by a CR) is sent.  The system
prompt is then sent.  Proper formatting of output insures that the EMSI_REQ
is  not see by terminal users.  We then monitor the line for an CR, if true
we  send  the  EMSI_REQ  and  system prompt again.  If any EMSI sequence is
received,  wplemsi.library  processes  the  handshake.   If  FTS1  or WAZOO
handshakes are received instead, they are processed.

    If  the  library  indicates  the  handshake  was  successful,  we check
password  and  process  link  and  compatibility  flags and invoke selected
protocol.

    XferQ Domain Substitution Override:

    If  the  domain  of  the  caller is FIDONET and the Zone is not a valid
FIDONET  Zone  (1-6),  we will attempt to determine the correct domain from
the zones in our AKA config.

    Point Correction:

    The  WPL  SetA  command  will  substitute  missing components of an FTN
address from the default address in Xferq:hostaddr.  Since the point number
is  not  presented if 0 under EMSI, this would result in the BOSS's address
being  changed to that of the point.  Shelter mailers detect this condition
and  change  the  BOSS's point number to 0, in order to restore the correct
address.

    Domain Correction:

    Some  mailers  (TrapDoor,for  example)  do not present the domain under
EMSI.   SetA  will  normally  substitute  our  site's  default  domain from
Xferq:hostaddr.   This  often  results in addresses with incorrect domains.
Shelter  Mailers  will  attempt to correct this also, using the domains and
zones in our own AKA's to try to determine the correct domain of the remote
site.

    Security:

    Since it is not possible to check that all AKAs presented are valid for
a remote site, we never BeginSession with the AKAs that the remote site has
presented.   Shelter  mailers  always  give primacy to the KNOWN AKA's of a
site over those it may present.  Other than a remote's Primary address, all
AKA's  a remote presents are IGNORED.  If the site is in our Site Cache and
the  password presented is valid for the primary address presented, we will
BeginSession with the KNOWN AKAs.
    If the site is NOT in our Site Cache (ie the site is not a KNOWN site),
we BeginSession with the primary address presented ONLY.


    Link and Compatibility Flag Processing:

    Presently,  a  strict  interpretation  of  the  EMSI  specification  is
implemented,  without  regards  to  the actual implementation in FrontDoor.
Link  Pickup  flags  are  only  presented when calling and are examined and
processed  only  when  answering.   Link Hold flags are only presented when
answering and are examined and processed only when calling.

    Link Flags:
    Link  codes  consist  of a string of flags that specify DESIRED CONNECT
CONDITIONS.  They apply to the CURRENT SESSION ONLY.  There are three TYPES
of link flags:  communications parameters, pickup options and hold options.

    Link Communications Parameters:
    Presented  by  both  the calling system and answering system, this flag
defines the communications link data bits, stop bits and parity parameters.
The  purpose  of  this flag is unclear however, my assumption is that it is
expected  that one end or the other change his communications parameters to
match.The specification does not say which end must compromise, nor what to
do  if a) no compromise is possible, b) software (such as wpl.library) does
not  support changing these parameters while connected.  Obviously, if only
one end changes link parameters, the session will fail.
    Shelter  mailers always use 8 bits, 1 stop, No parity and set the first
link  code  to  8N1.   Shelter  mailers do not take any action on the value
presented by the remote site.


    Link Pickup options:
        The  calling  system  can  present one of three Link Pickup options
related  to  pickup of mail.  These are presented during OUTGOING calls and
examined during INCOMING calls.

         /  PUA        Pickup mail for all presented addresses.
 one of |   PUP        Pickup mail for primary address only.
         \  NPU        No mail pickup desired.

    If none of these flags are presented, PUA is assumed.

    PUA:
        This  flag  is  presented  if DOMAINAWARE is TRUE.  These means our
tosser is zone and/or domain aware.

        This  flag  is not examined, since sending all mail for all akas is
the  default  action  under  EMSI.  The action to take if NO Pickup flag is
presented is undefined in the EMSI spec.  We assume PUA.

    PUP:
        This  flag is presented if DOMAINAWARE is FALSE.  On outgoing calls
with  Shelter's  PRIMARYONLY option set TRUE, the Primary address is always
that  address in the domain of the site we are calling.  Shelter will still
present PUP, but this is redundant.

        When examined, mail is sent for Primary (first) address presented.

    NPU:
        This  flag  is  presented  when using the Shelter dialer's NOPICKUP
session  option.  The presentation of NPU is a courtesy measure ONLY, since
we hangup after sending our mail.

        When  examined, NO files are sent, mail or OTHERWISE.  We do not do
a  BeginSession,  UNLESS  the  remote also presented PUP.  This would be an
error  on  his  part,  but we ignore that fact :) and just give him what he
wanted.


    Link Hold options:
        When  answering,  the  site  can  present Link Hold flags which are
requests  to  the  calling  site to not send certain types of files.  These
flags  should  be  presented  only  on  incoming calls and examined only on
outgoing calls.

             HRQ        Hold file requests (not processed at this time).
 and/or
         /   HAT        Hold ALL traffic.
 one of |
         \   HXT        Hold compressed mail traffic.


    HRQ:
        This flag is presented during UMH if STRICTZMH is TRUE.
        This  flag  is  also presented if host.freq is FALSE.  host.freq is
toggled FALSE when ALLOWFREQS is FALSE.

        When  examined,  remote.freq  is  set  FALSE  and  FindFreqs is not
executed. File requests are not sent to remote site.

    HAT:
        Never  presented.   I  can't  see this use right now...Disk Full ??
why  answer at all if you don't want to accept anything??

        When  examined,  BeginSession  is NOT executed.  This means that no
files are sent, but files can be received.

NOTE:  The existance of a flag which tells the caller not to send anything,
and  which  is  issued only when answering is somewhat strange.  For HAT to
serve  a purpose, the limiting of Link to calling systems and Hold flags to
answering system would have to be dropped.

    HXT:
        This flag is presented during UMH if STRICTZMH is TRUE.

        When examined, MinSendPri is set to 60.  In the Shelter system, the
result of receiving this flag is that files with a priority of less than 60
are  not sent.  Shelter's FLOCVT and ADDWORK functions set PKT's and CUT to
60  if not priority was specified.  This feature does not negate the use of
compressed netmail packets [*.sq(arctype)]


    Compatibility Flags:
        Compatibility  codes  consist of a string of flags that specify the
CAPABILITIES  (protocols  and archivers) and ENABLED FEATURES (file request
handler, filename conversion) of the mailer.

    Standard Protocol Flags:

        NCP     No common protocol ( a failure )

        DZA     DirectZAP (Zmodem variant).
        ZAP     ZedZap (Zmodem variant).
        ZMO     Zmodem w/1,024 byte data packets (Wazoo ZedZip).
        JAN     Janus
        KER     Kermit
        SLK     SeaLink

        WPL Only Protocol Flags:
        TEL     Telink  (FTS1)
        XMO     Xmodem  (DietIFNA)
        YMO     Ymodem
        UUG     uucp-g
        RYO     Roll Your Own :)

        Other:
        HYD     Hydra


    NCP:
        This  is presented if no compatible protocols (failure).  It logged
if  the  remote  presents  it.  We do not have any facility to present this
flag,  since  protocol  compatibility  is  determined AFTER emsi handshake.
Instead  we  fall  back  to DietIFNA.  Shelter, JamMail and Binkley support
this.


    Other Compatibility flags:

        NRQ     No file requests accepted by this system.

    NRQ:
        This flag should be presented if there is NO FILE REQUEST HANDLER.

        When examined, remote.freq is set FALSE.  No requests will be sent.

**NOTE:
        It  seems  some mailers present NRQ as the caller's version of HRQ.
My  impression  is  that  this  flag  is  presented  by  newer  versions of
wplemsi.library  if  host.freq  is  FALSE.   I  consider  this action even
when FrontDoor does it, to be incorrect since:

    - NRQ flag indicates NO REQUEST SERVER AVAILABLE
    - HRQ flag indicates NO REQUESTS AT THIS TIME.
    - Under  WAZOO,  the  lack of a NODELIST X?  flag is
      the equivalent to EMSI presentation of NRQ

        NRQ  should  be  presented  ONLY IF the mailer does not have a file
request  server.   In  other  words, the flag should be added during mailer
generation  and  never  be  based upon the state of the host.freq variable.
The internal <stem>.freq variable can mean EITHER hold requests or no request
server,  since  it  is  also  used  under  wazoo  which  does not have this
distinction.

        If  the  author  of the EMSI specification had intended that NRQ be
the  caller's  version  of  HRQ,  why  then  are  there  separate  LINK and
COMPATIBILTY flags, if they are not consistanty applied?  Why was there any
distinction made between calling and answering system LINK flags?  It would
be more consistant if ALL LINK flags be presentable by either system.
        In  fact,  for  consistancy,  the  chosen  protocol  should also be
presented as a LINK flag.

        ARC     ARCmail 0.60-capable, as defined by the FTSC.
                NO ACTION required

        XMA     Site supports other forms of compressed mail.
                NO ACTION required

        FNC     Filename conversion. This indicates that any transmitted
                filename must follow the CP/M & MS-DOS 8.3 restriction.
                An eight  character file name followed by a three character
                extension; eg. FILENAME.EXT
                NO ACTION POSSIBLE as yet. (See HXT/FNC discussion paper)

**NOTE:
        Since FNC is a compatibility flag, it SHOULD be interpreted to mean
that  the  system  presenting FNC is advertising the CAPABILITY to send 8.3
file names :) If the intention of the author of the EMSI spec was that this
was  a  request  for the other end to modify filenames, this should have be
stated.  The word 'received' should have been used instead of 'transmitted'
and the FNC flag should have been defined as a LINK flag for consistancy in
the specification.

                                   =eot=